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A METHOD FOR IMPLEMENTING 
COMPONENT OBJECT MODEL INTERFACES 

James A. Sievert 



5 FIELD OF THE INVPNTIQN 

The present invention generally relates to the 
Component Object Model (COM) and more particularly, to 
implementing a hierarchy of COM interfaces. 



10 BACKGROUND OF THE INVENTION 

The Component Object Model (COM) is a software 
architecture that supports reuse of software components 
between different application programs written in different 
languages. Reusing software components, where appropriate, 

15 reduces the cost of creating a new application as compared 
to creating an application from scratch, COM addresses the 
issues of interoperability where reuse is desirable for 
binary executables that are created by different entities in 
different languages . 

20 In COM, a "component" is a piece of compiled code that 

provides one or more services. It will be appreciated that 
even though a component is also an object in object oriented 
programming (OOP) terms, the term "component" will be used 
herein to avoid confusion with other objects in general. An 

25 "interface" is the mechanism through which components 

interact and through which software in general accesses the 
services of a component. The interface defines the behavior 
and responsibilities of the component. In other words, the 
interface is a group of related functions and forms the 
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binary standard or contract through which the component is 
accessed. 

A COM interface is not a class and cannot be 
instantiated by itself. A COM component must implement the 
5 interface, and the component must be instantiated for the 
interface to exist . It will be appreciated that the same 
interface can be implemented in different ways by different 
components with the restriction that each component must 
satisfy the interface's behavior and responsibilities. The 
10 information presented above, along with a more detailed 

explanation, is found in ''Dr. Dobbs Journal", December 1994. 

Sometimes it is desirable to implement a hierarchy of 
interfaces, which is often accompanied by a parallel class 
hierarchy, for example in C++. In implementing the 
15 component (s) behind the interfaces, ambiguity may result 
between certain method calls. Delegation is generally the 
method used to resolve ambiguity. 

The problem is illustrated with the following example 
COM interface hierarchy: 

20 
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int r£ace lAnimal : lUnknown 
HRESDLT eat () ; 

interface IPersoxi : lAnimal 
HRESULT talkO ; 

interface lEmployee : IPerson 
HRESULT work ( ) ; 

The hierarchy includes three interfaces: lAnimal, 
IPerson, and lEmployee. Interface lAnimal is a type of the. 
base interface, lUnknown, which is provided by COM; 
interface IPerson is a type of the lAnimal interface; and 
interface lEmployee is a type of IPerson interface. 
Interface lAnimal has a member method, eat(); interface 
IPerson has a member method, talkO; and interface lEmployee 
has a member method, workO . 

A parallel class hierarchy is often desirable when 
implementing such an interface hierarchy. Such a design 
allows the implementation of a given interface to be totally 
encapsulated by a single class. Initially consideration of 
implementing the above interface hierarchy in C++ leads to 
the following parallel class hierarchy: 
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typedef someType TStatus; 
class CAnimal 



virtual TStatus eat() 
{ ... } 



lass CPerson : public CAnimal 
virtual TStatus talk() 

{ ... } 



lass CEmployee : ptiblic CPerson 
virtual TStatus workO 

{ ... } 



The C++ access specifications (public, private, and 

protected) have been omitted to enhance readability. It can 

be seen that the classes CAnimal, CPerson, and CEmployee 

parallel the interfaces lAnimal, IPerson, and lEmployee in 

terms of inheritance and method definitions. The virtual 

methods eat(), talk(), and workO are included in the 

classes CAnimal, CPerson, and CEmployee, respectively. 

To implement the interface hierarchy along with the COM 

components, a C++ implementation begins with incorporation 

of the COM interface. Thus, the lAnimal interface may be 

implemented as: 

class CComAnixnal 

: public lAnimal 

{ 

STDMETHOD( eat ) () 
{ ... } 

}; 
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At this juncture, lAnimal defines an abstract method 
eat{), which has a concrete implementation in CComAnimal. 
It will be appreciated that STDMETHOD is a commonly used C++ 
preprocessor macro within the Microsoft C++ environment, 
5 The STDMETHOD 0 macro defines the standard calling 

convention and return type for a COM interface method. 

The following code shows analogous concrete 
implementations of the IPerson and lEmployee interfaces: 

10 class CComPerson 

: ptiblic IPerson, piiblic CComAnimal 

{ 

STDMETHOD ( talk ) {) 
{ ... } 

15 }; 

class CCoTTi Employee 

: public lEmployee, public CComPerson 

{ 

20 STDMETHOD ( work ) () 

{ ... } 

It will be appreciated that if the foregoing code is left as 
25 is, the multiple inheritance introduced from both IPerson 
and CComAnimal makes referencing the method 
CComPerson: : eat 0 ambiguous. That is, CComPerson: : eat () may 
be in reference to eat() of interface lAnimal (by virtue of 
inheritance from IPerson) or in reference to eat() of class 
3 0 CComAnimal. A similar ambiguity exists between eat() and 
talkO as defined in CComPerson and eat() and talk() as 
declared in lEmployee. Thus, using delegation, the 
ambiguity is resolved with the following example code: 
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class CComP rson 

: public IPerson, piiblic CComAnimal 

{ 

STDMETHOD( eat ) () 
5 { return CComAnimal :: eat () ; } 

STDMETHOD( talk ) () 
{ ... } 

}; 

10 

class CComEmployee 

: public lEnrployee, public CComPerson 

{ 

STDMETHOD( eat ) () 
15 { return CComPerson: : eat () ; } 

STDMETHOD( talk } () 

{ return CComPerson: : talk () ; } 

20 STDMETHOD{ work ) {) 

{ ... } ^ 

}; 



At this point, a C++ class implementation hierarchy has 
25 been defined that parallels the COM interface hierarchy. If 
the interfaces lAnimal, IPerson, and lEmployee had 
additional methods, then additional delegation code would be 
required. Furthermore, if the interface hierarchy had been 
deeper, more delegation code would be needed. 
30 While the delegation code provides a functioning 

implementation, understanding the implementation from a 
developer's point of view may be difficult because of the 
complex inheritance relationships and the representation in 
an object diagram. 
35 FIG. 1 is an object model diagram that illustrates the 

class relationships of the class definitions set forth in 
the preceding code. It can be seen from the diagram that 
some of the classes inherit from two classes. For example. 
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the CComEmployee class inherits from the CComPerson class 
and lEmployee interface. In addition, the lEmployee 
interface inherits from the CComAnimal class and the IPerson 
interface . 

5 A method that addresses the aforementioned problems, as 

well as other related problems, is therefore desirable. 

SUMMARY OF TPP IWVEWT3;C > N 

In various embodiments, the invention provides a method 

10 for implementing a hierarchy of component object model 
interfaces. A hierarchy of component object model 
interfaces is defined in which an interface at a lowest 
level of the hierarchy inherits from an interface at the 
highest level of the hierarchy. A class is defined that 

15 includes a first template class that is associated with the 
highest level of the hierarchy. A second template class 
inherits from the first template class and is associated 
with the lowest level of the hierarchy. The second template 
class is instantiated with an interface as a template 

20 parameter. Thus, the instantiation of an object of the most 
specialized class provides the base interface from which the 
most generalized class derives. 

In accordance with another embodiment of the invention, 
there is provided a computer program product that is 

25 configured to be operable to implement a COM interface 

hierarchy without using delegation methods. In the computer 
program product, an object of the most specialized class 
provides the base interface as a template class parameter, 
from which the most generalized class derives. 
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The above summary of the present invention is not 
intended to describe each disclosed embodiment of the 
present invention. The figures and detailed description 
that follow provide additional example embodiments and 
5 aspects of the present invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other aspects and advantages of the invention will 
become apparent upon review of the Detailed Description and 
10 upon reference to the drawings in which: 

FIG. 1 is an object model diagram that illustrates the 
relationships of a Component Interface Hierarchy and the 
associated class definitions when using delegation methods; 
and 

15 FIGs. 2A and 2B are object model diagrams that 

illustrate the interface and class hierarchies, 
respectively, in practicing one embodiment of the invention. 

While the invention is susceptible to various 
modifications and alternative forms, specific embodiments 

20 thereof have been shown by way of example in the drawings 
and will herein be described in detail. It should be 
understood, however, that the detailed description is not 
intended to limit the invention to the particular forms 
disclosed. On the contrary, the intention is to cover all 

25 modifications, equivalents, and alternatives falling within 
the spirit and scope of the invention as defined by the 
appended claims . 
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The present invention is believed to be applicable to a 
variety of object-oriented applications. The invention has 
been found to be particularly applicable and beneficial for 
5 applications written in C++ for the Component Object Model. 
While the present invention is not so limited, an 
appreciation of the present invention is presented by way of 
an example COM interface hierarchy. 

In accordance with the embodiments described herein, 
10 the delegation methods are eliminated using a single 

inheritance implementation. In implementing the example set 
forth in the Background section using single inheritance, 
CComAnimal inherits from the "most derived" or most 
specialized interface, lEmployee. Further derivations of 
15 CComPerson and CComEmployee are implemented so as to 

provide concrete implementations of the abstract methods 
declared in the more specialized interfaces. 

An example for illustrating the embodiments of this 
invention begins with the following code: 

20 ■ 
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class CComAnimal 

: public lEinployee 



STDMETHOD( at } () 
{ ... } 



class CComPerson 

: public CComAnimal 

STDMETHOD( talk ) () 
{ ... } 



class CComEmployee 

: public CComPerson 

STDMETHOD( work ) () 
{ ... } 



This code eliminates the delegation methods described above 
because each method is unambiguously defined. The 
implementation has as a disadvantage the least specialized 
class, CComAnimal, inheriting from the interface of the 
most specialized class, CComEmployee. The problem created 
is that the developer of CComAnimal may not know a-priori 
the interface from which to inherit because the another 
developer may define the most specialized class at a later 
time. This lack of information limits future re-use 
possibilities for the CComAnimal class. 

Consider further extension of the example such that an 
interface lEmployeeEx inherits from IPerson, and 
lEmployeeEx is implemented by CComEmployeeEx that inherits 
from CComPerson. With the addition of lEmployeeEx and 
CComEmployeeEx, there are no clear a-priori options for the 
developer of the CComAnimal class in terms of interface 
inheritance . 
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In one embodiment, C++ templates are used to implement 
the single inheritance method of the present invention. In 
the example code below, the templates provide a convenient 
means by which to choose the correct interface from which 
CComAnimal inherits in a single inheritance scheme. The 
following code illustrates a template-based single 
inheritance implementation • 

template< typename Baselnterface > 
class CComAnimal 

: public Baselnterface 

{ 

5 STDMETHOD( eat ) {) 

{ ... } 

}; 

template< typename Baselnterface > 
10 class CComPerson 

: public CComAnimal< Baselnterface > 

{ 

STDMETHOD( talk ) () 
{ ... } 

15 }; 

template< typename Baselnterface > 
class CCoinEinployee 

: public CComPerson< Baselnterface > 

20 { 

STDMETHOD( work ) () 
{ ... } 

}; 

25 From the preceding code it can be seen that the inheritance 
hierarchy provides a method by which the most derived class 
can establish the base interface for CComAnimal. That is, 
code instantiating the template CComEmployee would provide, 
as a template parameter, the base interface from which 

3 0 ultimately, CComAnimal would derive. The template 

capability of CComEmployee provides better extensibility in 
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that a subsequent developer could derive from CComEmployee, 
specifying yet another interface base class. 

The syntax given above is typical of C++ template 
declaration. Stated simply, Baselnterf ace is a parameter 
5 to be supplied at compile time that specifies some type 
(class, struct, and/or interface) . The compiler 
substitutes the specified type wherever Baselnterf ace is 
declared. An example usage is 

10 CComEmployee<IEmployee> employee 

Here, the variable employee is of type 
CComEmployee<IEmployee> . Through template substitution of 
lEmployee for Baselnterf ace, CComEmployee<IEmployee> itself 
15 derives from CComPerson< lEmployee > . Because CComPerson is 
itself a template class, CComPerson< lEmployee > derives from 
CComAnimal < lEmployee >. Finally, because CComAnimal is a 
template class, CComAnimal derives from lEmployee, which 
was the ultimate goal. 
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In another embodiment, the class CComEmployee could be 
declared as "class CComEmployee: pxiblic 
CComPerson<IEmployee>. " This embodiment provides the 
lowest level interface, lEmployee, as a parameter to the 
5 CComPerson template directly in the class definition for 
CComEmployee. As with the previously described embodiment, 
this embodiment also eliminates the need for delegation 
methods. Since the interface is provided as the parameter 
to the CComPerson template in the class definition, the 

10 instantiation of a CComEmployee object does not require 
providing the lEmployee parameter as for the previously 
described embodiment. 

It will be appreciated that this invention eliminates 
delegation through unambiguous method definition while 

15 allowing the most specialized class to specify the 
interface from which the base class will inherit. 

FIGs. 2A and 2B are object model diagrams that 
illustrate the interface hierarchy and the class hierarchy 
of the implementation example set forth above. The 

20 interface hierarchy of FIG. 2A shows the interfaces 

lAnimal, IPerson, and lEmployee as blocks 202, 204, and 
206, respectively. Interface lEmployee is a kind of 
IPerson interface, and interface IPerson is a kind of 
lAnimal interface. The interfaces lAnimal, IPerson, and 

25 lEmployee include the public methods eat(), talk(), and 
workO , respectively. 

FIG. 2B shows the class hierarchy for implementing the 
COM interface in C++ classes that parallel the interface 
hierarchy. Block 252 represents the Baselnterf ace 

3 0 template, and block 254 shows that class ComAnimal is a 
kind of Baselnterf ace template and has the member method 
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eatO. Class ComPerson, as shown by block 256 includes the 
member method talkO and is a kind of ComAnimal . 

Block 258 shows that class ComEmployee is a kind of 
ComPerson and has the member method workO . 
5 By convention, a modeled class is called "MyClass." 

When codified, MyClass becomes ''CMyClass." 

In another embodiment, the preceding implementation 
can be combined with the ActiveX Template Library (ATL) . 
ATL is a constituent part of the Microsoft C++ development 
10 environment. ATL provides an infrastructure for the rapid 
development of COM objects in a Microsoft C++ development 
environment . 

ATL allows each level of the inheritance hierarchy to 
establish and evaluate its own ATL interface map. The ATL 

15 interface map is a mechanism by which one can furnish the 
interfaces available from a COM object to the underlying 
ATL infrastructure. The importance of each level of the 
inheritance hierarchy establishing and maintaining its own 
interface map stems from notion of functionality 

2 0 encapsulation that classes provide. 
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The code below illustrates the ATL implementation. 

teiaplate< typenam Bas Interface > 
class CCoxaAnizoal : 

public CComObjectRootEx 
5 < model-of -your-choice >, 

public Baselnterface 

{ 

BE6IN_COH_M2^ ( CCoiiAniiaal< Baselnterface > ) 
COM_INTERFACE_ENTRY { lAnimal ) 
10 EKD COM MAPO 



15 



25 



STDMETHOD( eat ) () 
{ ... } 



template< typename Baselnterface > 
class CCozoPerson : 

public CCoinAniiiial< Baselnterface > 

{ 

20 BEGIN_COM_MAP ( CCoinPerson< Baselnterface > ) 

COM_INTERFACE_ENTRY ( IPerson ) 
COM_INTERFACE_ENTRy_CHAlN 

( CComAniiaal< Baselnterface > ) 
END COM MAPO 



STDMETHOD( talk ) () 
{ ... } 



3 0 template< typename Baselnterface > 

class CCozoEmployee : 

pxiblic CComPerson< Baselnterface > 

{ 

BEGIN_COM_MAP ( CComEnqployee ) 
35 COM_INTERFACE_ENTRy ( lEmployee ) 

COM_INTERFACE_ENTRY_CHAIN 

( CCoiaPerson< Baselnterface > ) 
ENDCOMMAP ( ) 

40 STDMETHOD( work ) () 

{ ... } 

}; 

In the ATL implementation, each level of the 
45 inheritance hierarchy is responsible for implementing its 
own interface. The ATL implementation differs from the 
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implementation associated with FIGs. 2A and 2B in how 
interface support is made available to the ATL 
infrastructure . 

As a result, the appropriate interface is added to the 
5 interface map at each level of the hierarchy. Furthermore, 
specialized levels of the hierarchy use 

COM_IlsrTERFACE_ENTRY_CHAIN ( ) to delegate to implementations 
in less specialized classes. 

It will be appreciated that the ATL implementation 

10 provides independent levels of interface selection. That 
is, each level of the inheritance hierarchy exposes only 
those interfaces directly implemented at the particular 
inheritance hierarchy level . Such a design provides strong 
encapsulation of interface exposure. 

15 The embodiments described herein provide a method that 

eliminates the need for delegation methods when 
implementing COM interface hierarchies with a parallel C++ 
class hierarchy. The implementation method saves time when 
coding COM objects in C++ that implement a COM interface 

20 hierarchy and can be easily coupled with ATL to provide 
independent levels of interface selection. 

Accordingly, the present invention provides, among 
other aspects, a method for implementing COM interface 
hierarchies. Other aspects and embodiments of the present 

25 invention will be apparent to those skilled in the art from 
consideration of the specification and practice of the 
invention disclosed herein. It is intended that the 
specification and illustrated embodiments be considered as 
examples only, with a true scope and spirit of the invention 

30 being indicated by the following claims. 



16 



